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Abstract 

As systems become ever more complex, verification becomes more 
main stream. Event-B and Alloy are two formal specification languages 
based on fairly different methodologies. While Event-B uses theorem 
provers to prove that invariants hold for a given specification, Alloy uses 
a SAT-based model finder. In some settings, Event-B invariants may not 
be proved automatically, and so the often difficult step of interactive proof 
is required. One solution for this problem is to validate invariants with 
model checking. This work studies the encoding of Event-B machines 
and contexts to Alloy in order to perform temporal model checking with 
Alloy's SAT-based engine. 



1 Introduction 

Current day systems are ever more detailed and complex leading to the necessity 
of developing models that abstract unimportant implementation details while 
emphasizing their structure. These models are developed in order to be easily 
verified either by theorem provers or model chec kers. 



EvENT-B is a language based on B-METHOD (jAbriall |1996l |). and supported 



by the open tool RODINQ. Part of the lang uage is developed v isually and there 



is a syntax for predicates and expressions (jConsortiuml [2005[)- The RODIN 
tool is shipped with theorem provers which allow the user to prove the model 
invariants e ither automati cally or interactively. 



Alloy ( JacksonI 2002l | ) is a structural modeling language based in first order 



logic. It is a textual language that consists of signatures, which introduce flat 
relations, functions, predicates and assertions that deal with the relations. By 
specifying predicates and assertions it is possible to perform model finding or 



model checking. The tool uses KodKod (jTorlak and JacksonI [2007| ). a model 
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finder, to convert the model within given bounds to SAT and return an instance 

of the model or a cou nter-example. 

In previous work (jMikhailov and Butlej |2002| ) B -METHOD was combined 
with Alloy, since then Alloy was considerably improved and extended by, 
not only, adding new constructs but also by making the verification much more 
efficient. The restrictions described in the work either do not exist anymore or 
they can be overcome. 

Until recently it was only possible to perform temporal model checking in 
an EVENT-B model by using a two step process: conver ting the model to B- 
METHOD and then using ProBl Leuschel and Butler 2003l |). However, the solu- 
tion was not straightforward as the conversion to B-METH OD was not always 



fully automated. More recently, a prototype ProB pluginl Ligot et al. 2003]) 



for the RODIN tool has been developed that provides an alternative solution 
for model checking Event-B models using the ProB model checker. Never- 
theless, encoding Event-B to Alloy allows building on top of the Alloy 
model finding engine therefore benefiti ng from all of its optimizations. As 
mentioned elsewhere (jLigot et al.l 2007| ). encoding Event-B is not straight- 
for ward but this work show s it is possible. This work has been published 
in (jMatos and Margues-SiTval |2008l |). 



2 Encoding 

This section summarizes the process of encoding an Event-B model into Al- 
loy. Due to space constraints the presentation will be informal and far from 
complete, which means that there are Event-B operators for which an encod- 
ing has been developed but which are not described. A full example, based on 
processes and mutexes, including the actual encoding and additional comments 
will be shown in section [3l For a detailed desc ription of the struc ture and rules 
of EVENT-B models the reader is referred to ( Consortium! 2005j |). 



There are three aspects to the encoding: encoding of the model structures, 
expressions, and predicates (which are straightforward due given the existence 
of the logical operators in both languages) . 

The execution model needs to be emulated by the final Alloy model. To 
this end all of the encoded models define a "State" signature which is ordered by 
using the ordering module and with as many fields are there are variables. The 
variable types are extracted from the set of Event-B invariants and encoded 
into signatures which become the type of the respective fields. A fact defines 
the initial state which is encoded from the "Initialisation" event. Each event 
is encoded in a predicate with two arguments: the current state and the next 
state and it evaluates to true whenever the next state reflects the triggering of 
an event from the current state. A final fact asserts that at every state one of 
the events needs to be triggered. 

A carrier set is encoded as a signature with no fields and an enumerated set 
is encoded as signature, one per enumeration, with no fields that extend a base 
signature that represents the type of the enumerated set. One special enumer- 
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ated set "Events" has one enumeration per event, plus an "Undef" enumeration 
for the initial state which is defined to be triggered by an "Undef" event. "Ev" 
is the type of a special field in the "State" signature. If "Ev" is x in state s', 
this means that it was the triggering of x that caused the transition from s to 
s'. Although this information is not necessary for the model checking itself, it 
makes the state trace of a failed invariant much more readable. 

Expressions are the hardest part to encode. There is not only a myriad of 
complex expressions in Event-B but given that Alloy uses only flat relations, 
some EvENT-B expressions that introduce relations with nested sets generate 
many (and potentially large) Alloy expressions. Some expressions are straight- 
forward like the domain, range, domain and range restriction and their subtrac- 
tion counterparts, since they are either already defined in modules shipped as 
part of the current Alloy distribution or they are very easily defined as small 
functions. Operators like prjj^, prjj and id need to be defined as Alloy functions 
in order to be used. All arithmetic operators except power are defined but still, 
power can be defined explicitly during encoding-time depending on the defined 
bit width passed on to the Alloy engine for checking. For example, could 
be defined as a = ^ 1 else b = 0^0 else 6 = 1 a else 6 = 2^ a.mult[a] ■ ■ ■. 
Function expressions can be encoded as relations and then facts can be added to 
the model as to assure the semantics is preserved. So, to encode {A^B)^C, a 
signature with a relation from Ato B would be defined followed by a fact assert- 
ing the relation to be a total function and then yet another signature is defined 
with a relation from the previously defined signature to C. Although function 
nesting requires a new signature, it seems this is the best general solution given 
that Alloy only works with flat relations. 

3 Example 

This section presents an example of the encoding. Although the example is 
simple, it is enough to have an idea of how it works. The example is based on 
the Alloy model dijkstra.als distributed with Alloy 4.1. 

The EvENT-B specification is shown in table [TJ It introduces two carrier 
sets, the processes set and the mutexes set, and two relations between processes 
and mutexes. The pair {p i— > m} is in the relation Holds iff the process p holds 
the mutex m and it is in the relation Waits if p is waiting for m to be released 
in order to hold it. There are three events which control the holding and release 
of mutexes by processes. The "HoldOnMutex" event is triggered for a process 
p and a mutex m if p is not waiting for any mutex and it does not already 
hold m. Once it is triggered p holds m by adding the pair {p i— m} to the 
Holds relation. The "WaitOnMutex" event is triggered when process p has to 
wait to hold m because there is already some other process holding it. The 
"ReleaseMutex" is the counterpart to "HoldOnMutex" and allows a process to 
release a mutex it no longer needs. This very simplistic model allows us to 
exercise the encoding presented in the paper. The carrier sets and the enumer- 
ated set for event types are immediately encoded into several signatures as seen 
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Table 1: Mutexes Event- B Specification 



Carrier Sets 


Event HoldOnMutex 


Process 


Guards 


Mutex 


p G Process 


Variables 


m G Mutex 


Holds 


p ^ dom{Waits) 


Waits 


m ^ va.n{Holds) 


Initialisation 


Actions 


Holds := 


Holds : = Holds U h-> m} 


Waits := 


Event WaitOnMutex 


Event ReleaseMutex 


Guards 


Guards 


p G Process 


p e Process 


m G Mutex 


m G Mutex 


p ^ dom{Waits) 


p ^ dom{Waits) 


m G ran({p} ^ Holds) 


m e ran({p} < Holds) 


Actions 


Actions 


Waits := Waits U {p i— > m} 


Holds : = Holds \{p>-^ m} 


Invariants 




Holds G Process Mutex 




Waits G Process ^ Mutex 




dom.{Waits) ^ Process 
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Table 2: Carrier Set and Enumerated Set Encodings 



sig Process {} 
sig Mutex{} 
abstract sig Events{} 

one sig Undef, HoldOnMutexE, WaitOnMutexE, 



ReleaseMutexE extends Events{} 





Table 3 


: State Signature and Types 




sig HoldsRel{ 
rel : Process — 

} 


-> Mutex 


sig WaitsRel{ 
rel : Process — > Mutex 
} 


sig State{ 
Holds : HoldsRel, 
Waits : WaitsRel, 
Ev : Events 

} 



in table [21 The state signature along with the types of the Holds and Waits 
relation, which are extracted from the invariants is shown in tabled Although 
it would be possible to define the relations Holds as Holds : Process — > Mutex 
and analogously for Waits we didn't do that in this case because the encoding 
of EvENT-B expressions as {{A -i^ B) ^ C) is done recursively on the structure 
of the expression generating n + I signatures for n operators. 

The initialisation event is encoded as a fact that sets the initial state sO, and 
is shown on the left side of table S) This encoding just defines the variable sO 
as the first element of the state ordered set and then sets each field of the state 
with its initial value. On the right side the trigger is a fact that forces for each 
state transition one of the events to trigger. 



Table 4: Event Initalisation 



fact Initial { 




fact EventTrigger{ 




let sO = ord/ first{ 




all s : State — ord/ las 


t{ 


sO.Holds.rel = none - 


-> none 


let s' — ord/next[s]{ 




sO.Waits.rel = none - 


none 


HoldOnMutex[s, s'] 


or 


sO.Ev = Undef 




WaitOnMutex[s, s' 


] or 


} 




ReleaseMutex[s, s' 




} 




} 
} 
} 
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Table 5: Event WaitOnMutex 



pred WaitOnMutex[s, s' : State]{ 
some p : Process, m : Mutex{ 
1 1 Guards 

!(p in dom \sW aits.reV\) 

m in ran[(doni[s. iJoWs.re^] — {p}) <: s.Holds.rel] 
1 1 Action 

s' .Waits.rel = s.Waits.rel + {p — > m} 
s' .Holds = s. Holds 
s'.Ev = WaitOnMutexE 
} 

} 



Table 6: Event HoldOnMutex and ReleaseMutex 



pred HoldOnAIutex[s, s' : State\{ 


pred ReleaseMutex[s , s' : State\{ 


some p : Process, m : Mutex{ 


some p : Process, m : Mutex{ 


II Guards 


1 1 Guards 


!(p in dom[s.M^a?is.re/]) 


\{p in doials. Waits.rel]) 


!(m in ran[s._ffoWs.re^]) 


m in ran[{p} <: s.Holds.rel] 


/ / Action 


1 1 Action 


s' .Holds. r el = s.Holds.rel + {p — > m} 


s' .Holds. r el — s.Holds.rel — {p ^ m\ 


s'. Waits — s.Waits 


s' .Waits = s.Waits 


s'.Ev ^ HoldOnMutexE 
} 
} 


s' .Ev = ReleaseMutexE 
} 
} 



The events are encoded by translating each of the guards and actions into 
Alloy expressions. Table[5]presents the encoding for the WaitOnMutex event. 
Most of the encoding is straightforward, except for the case of the domain 
subtraction operator that is encoded into Alloy using its definition based on 
the domain restriction operator. Note that in Alloy, whenever the actions do 
now span all of the state variables, it is necessary to state that they are equal 
to the previous state. 

The HoldOnMutex events and its counterpart ReleaseMutex are shown 
in table [6] on the left and right side respectively. The events are similar and 
their encoding just transforms the Event-B operators into those recognized by 
Alloy. Given a syntactically correct Alloy module header, it is possible to 
verify the Alloy model by encoding the invariant as an assertion: 

assert N oDeadlock{al\ s : State \ \{doT[i[s.Waits.rel] — Process)} 
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and using the check command to verify it. The following check finds a deadlock 
within 6 states, 2 processes and 2 mutexes. This translates analogously into 
EVENT-B. There is an invariant failure within 6 event transitions for 2 processes 
and 2 mutexes. 

check NoDeadlock for exactly 6 State, exactly 2 Process, exactly 2 Mutex, 

exactly 6 HoldsRel, exactly 6 WaitsRel 

The second line of the check command specifies necessary bounds based 
on the number of states Alloy should check. The number of such auxiliary 
signatures is always equal to the number of states. 

4 Conclusion and Future Work 

The focus of our work is to allow the users of the Event- B language to use the 
years of work and expertise in the development of the Alloy tools. This paper 
summarizes an encoding of Event-B into Alloy. The resulting Alloy model 
can serve to find counterexamples to false invariants and translate them back 
to Event- B. Future work entails the automatic generation of the encoding and 
its integration with the RODIN tool. The tool to be developed can then be 
extended to use other backends besides Alloy. Although this work focuses on 
model checking, there are cases where it is desirable, and often the preferred 
alternative, to do constraint based checking. We will investigate line of work as 
another possible extension to the tool. 
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